Developers writing web applications with ASP.NET or other development technologies typically create web user interface and logic (such as page handling logic like button click events and business objects) in traditional web pages and other affiliated class libraries. That web site is then hosted on a server within the company, or by an external service provider host.
It is increasingly becoming common and important to share data and functionality that enables mashup-like scenarios often found in the portals of today. Generally this has been done in two forms. The first form is to expose raw data by services for use by one or more portals in the mashup. The second form is to write data, user interface, and logic specifically as a gadget or plugin. In this latter scenario, developers create specific snippets of web functionality, like a clock user interface gadget, or a stock gadget that is registered with a particular host, such as a portal host. An end user that browses the host can then select these gadgets to build up a personalized web page at the host.
In both situations, a lot of extra effort is required if the same functionality is desired for a mashup scenario, as well as for a standard web page that is not involved in a mashup scenario. This is because the developer must write the code for the standard web page, and then separately write the code to create the gadget or service that can be used in the mashup scenario.